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"A network-based billing method and system" 

INTRODUCTION 
5 Field of the Invention 

The invention relates to billing in a network environment in which server 
applications communicate with clients via a gateway. The term "gateway" is 
intended to mean any access or routing device between server applications and 
1 0 clients. It may, for example be a WAP gateway, in which case the clients are mobile 
handsets. 

Prior Art Discussion 

15 At present, there are quite extensive mechanisms for processing subscriber billing 
data in telecommunication networks such as mobile networks. However, such 
processing has been inflexible and so only generate billing data according to limited 
parameters such as time duration of a call. Such an arrangement is described in 
United States Patent Serial No. US5873030 (MCI), in which local mobile networks 

20 connect with a national mobile service platform (MNSP) to provide traffic-related 
billing data. 

Objects of the Invention 

25 It is therefore an object of the invention to provide for more flexible billing data 
processing in a network environment, 

SUMMARY OF THE INVENTION 
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According to the invention, there is provided a method of capturing billing data for 
operation of an apphcation on a netv^ork server communicating with a cUent via a 
gateway, the method comprising the steps of:- 

5 the apphcation automatically generating billing data relating to a service it 

provides; 

the application automatically transmitting the billing data to the gateway; and 
1 0 the gateway processing the billing data. 

In one embodiment, the application transmits the bUling data in an event message 
according to a pre-set format. 

15 In another embodiment, the message comprises a HTTP header. 

In one embodiment, the application generates a message for each activity recognised 
as an event and transmits said messages to the gateway. 

20 In another embodiment, the application recognises a plurality of events for a 
transaction. 

In a further embodiment, the application includes a common event linkage identifier 
in each event message associated with a particular transaction. 

25 

In one embodiment, the application recognises a transaction failure as an event. 
In another embodiment, the application recognises a time-out as an event. 
30 Preferably, each event message has a unique identifier. 
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In one embodiment, the identifier is a number whereby identifiers of sequential 
messages are sequential numbers. 

5 In another embodiment, each event message comprises at least one parameter value. 

In one embodiment, each parameter value is represented in a tag-length-value format 
in which a tag field identifies a parameter name, the length field identifies the length 
of the value in bytes, and the value field contains the parameter value. 

10 ! 

In another embodiment, the gateway generates billing data according to signal flows 
between the application and the client, and stores said billing data in addition to that 
originating from the application. 

15 In a fiirther embodiment, the gateway recognises events according to signal flows 
between the application and the client, and generates corresponding messages. 

In one embodiment, the gateway routes event messages to a billing log for off-line 
processing or to a real time mediation device for real time processing according to 
20 configuration settings. 

In another embodiment, the gateway routes event messages to the real time 
mediation device if the events relate to pre-paid services. 

25 In a further embodiment, within the gateway, messages are routed in real time to a 
billing manager, and said billing manager processes the messages. 

According to another aspect, the invention provides a gateway for routing of signals 
between a client and an application hosted on a network server for performance of a 
30 transaction, the gateway comprising: 
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means for receiving billing data from the application, said billing data relating 
to a service provided by the application; and 

5 means for processing the biUing data. 

In one embodiment, the processing means comprises means for classifying the data 
as requiring real time processing or off-line processing, and for routing the data 
accordingly. 

In another embodiment, the billing data is incorporated in event messages. 

In a fiirther embodiment, the gatev^^ay comprises means for generating event 
messages according to handling of signals for transaction. 

In one embodiment, the gateway comprises a billing manager, means for routing 
billing data in real time to the billing manager, and means in the billing manager for 
directing storage of the data in a log for off-line processing or for routing the data to a 
real time mediation device for real time processing. 

According to a still further aspect, the invention provides a billing system 
comprising: 

a gatevi^ay as described above; 
25 

a mediation device comprising means for reading billing data in a billing log 
which is updated by the gateway and for processing said billing data; and 

a real time mediation device comprising means for performing real time 
30 processing of billing data received from the gateway. 



15 



20 
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DETAILED DESCRIPTION OF THE INVENTION 

The invention will be more clearly understood from the following description of 
5 some embodiments thereof, given by way of example only with reference to the 
accompanying drawing which is a schematic representation of a billing data 
processing method and system. 

Referring to Fig. 1, there is shown a WAP gatevv^ay 1 communicating with a Web (or 
10 "origin") server 2 hosting Web-based applications such as on-line shopping i 
applications. The gateway 1 communicates with mobile handset clients 3 via a 
mobile network 4. The gateway 1 maintains a billing log 5, and the log 5 is accessed 
by a billing mediation device 6. The gateway 1 also communicates with a real time 
billing mediation device 7. The gateway 1 comprises an internal software function 
1 5 called a Billing Manager. 

An application on the server 2 carries out its operations in conventional manner for 
processing transactions. However, the application is also programmed to generate 
messages including a billing-related HTTP header. The header is in a pre-set format. 
20 which may be published and used by many Web-based applications on many Web 

servers. In this embodiment the header has the format '*x-up-billing-info: A 

simple example is '*x-up-billing-info:245" to indicate to the gateway 1 that a user (of 
the client handset 3) has made on-line shopping purchases worth $245 while 
accessing that application. 

25 

The application generates the messages in response to events associated with the 
service being provided. These events will not all be "billable" and so some messages 
do not include billing headers. 



BNSDOCID: <W0 01 581 10A2J_> 



wo 01/58110 



PCT/IEO1/0O0I6 



-6- 

The gateway 1 detects and extracts each such header. In this embodiment, this is 
performed by code in the gateway stack recognising the header. The header is 
forwarded in real time to the (internal) Billing Manger. 

5 Where the billing data is not required to be processed in real time, the Billing 
Manager sends the contents of the billing header (together with any others received 
in the preceding period) to the billing log 5. In this embodiment, the billing log 5 
resides on the gateway 1, however, it may reside on an external entity. 
Subsequently, the bilhng mediation device 6 (which is operated by the mobile 
10 network operator) accesses the billing log and uses the data for billing purposes. For 
example, the mobile network operator may use the data to charge the user or the 
operator of the application a handling fee of say, 1% of the transaction value. Thus, 
the invention allows parties who are not hosting the application to make charges for 
service events on an agreed basis with the application host organisation and the user. 

15 

In the embodiment described above, the header value is a single numeric value, 
however, it may be a combination of both text and numerical information and the 
content of the header may be set according to the particular application. 

20 The Billing Manager may route the billing data to the mediation device 7 in real 
time. Also, the gateway 1 may transmit the billing data to the client. 

In more detail, an event reflects some aspect of the processing of a transaction, and a 
transaction is a complete request/response cycle from the user's perspective. Each 
25 message generated in response to an event contains a number of fields, which hold 
common information such as source, destination addresses, and data specific to the 
event itself such as the URI being retrieved or the volume of data downloaded. 

Multiple messages may be created for a single transaction. Each message has a 
30 numeric identifier, and all messages that relate to the same transaction are linked 
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with a unique number, called the event linkage id (ELID). The ELID is used to ensure 
that all messages related to one transaction can be associated, for example during 
processing by a billing mediation device 6 or 7. The gateway manages the generation 
and allocation of ELIDs. 

5 

The internal components of the gateway (for example processes) also recognise 
events to mark the progress of a transaction at discrete points, for example, when a 
response is received from the Web server or when the content has been confirmed to 
have been received by the client etc. As each event is recognised an associated 
10 message is communicated in real-time to the Billing Manager. 

The Billing Manager may write the message (or some of its data) to the billing log 5 
and/or can send it direcdy (in real-time) to a real-time billing mediation device 7. 
The choice of whether to write the message to the billing log or send it via the real- 

15 time interface is configurable within the gateway 1. For example, real-time output 
might be used for prepaid subscribers to allow their available credit to be updated as 
they perform transactions, while the billing log 5 might be used for post-paid 
subscribers who are billed periodically. The exhaustion of a pre-pay user's credit 
would be detected by the real-time billing mediation device, and the configuration of 

20 the gateway components would automatically be updated to deny service to that 
particular subscriber. Subsequendy, when the user's credit is re-established the 
configuration of the gateway would be altered to permit subscriber requests. 

Each message is formatted as a Tag-Length-Value (TLV) as described in more detail 
25 below. Messages are written to the billing log file in their TLV format. For the real- 
time interface, a TCP socket connection is established between the Billing Manager 
and the real-time billing mediation device 7. The Billing Manager outputs the 
appropriate messages direaly onto this connection. 
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A transaction is generally regarded as a single request and response between the 
client and the Web server. The transaction may have been initiated either by the 
client (pull) or by the web server (push). The puU model is used in the following 
description, but it applies equally to the push model. 

A transaction may result in a number of distinct events, each of which is logged 
separately; the messages of events for a particular transaction have the same ELID, 
and so all the events for a transaction can be associated. It is the responsibility of the 
billing mediation device 6 (or some other external system) to reconcile the events for 
a particular transaction into meaningful billing information for the operator. 

While the gateway can track (and record events for) individual transactions between 
the client and the web server, it has no understanding of the content or value of the 
service being provided to the user of the client. For example, when accessing a 
1 5 banking application, a user probably has to navigate through a series of menus in 
order to achieve the service. In a scenario where a user wants to transfer money from 
one account to the other, an interaction with the web server might be as follows. 

1. The user enters his usemame and secret password to get access to the basic 
20 menus 

2. The user selects Account Transfer (rather than Balance Enquiry, Chequebook 
Order, Bill Payment, etc.) 

3. The user selects the two accounts for the transfer and the amount to be 
transferred 

25 4. The application asks the user to confirm the transfer, possibly requesting that the 
password is re-entered. The success of the transfer is indicated to the user. 

5. The user would then sign-off from the application. 



5 



10 
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This simple service could result in as many as five events, but it is the fourth event 
that provides the real value for the user and the application provider, i.e. the 
successful transfer of money from one account to the other. If the user entered the 
wrong usemame or password, or unknown account numbers, or the bank was not 
5 allowing transfers at this moment in time, transactions would still take place between 
the client and the web server, but no valuable service has been provided to the user. 
Similarly, moving £1000 from one account to the other might be considered to have 
more value than a balance enquiry or ordering a chequebook. 



10 The gateway 1 cannot determine (purely from the transaction) whether a useftil 
service has been provided to the user, or how useful/valuable that service was. 
Therefore, it would not be possible for the operator to take account of the value of 
the service provided in billing (or indeed not billing) the user. Only the application 
(resident on the Web server) can determine in all circumstances whether a service 

1 5 has been provided and the degree of value. 



The invention provides a major advance for the network operator as it allows it to 
enhance its billing strategy and differentiate itself from competitors. The application 
can include any information it wishes in the billing header, for example the success 
20 of the service, the value of the service (e.g. £1000 transferred), the names of the 
books the user purchased, etc. The format of the information just needs to be agreed 
between the operator and the application. 



The billing header is included in one or more of the event messages created for the 
25 transaction. The operator can then consider the information in the billing header 
when determining whether and how much to bill the user for the service. For 
example, the operator might choose not to bill the user for any of the transactions 
unless the user was successftilly provided with a service; or the user might be billed a 
small amount for each transaction, and then an additional fee for successful services; 
30 and some services might be premium rate, while others might be lower rates. The 
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operator might enter into an agreement with the apphcation provider where the 
operator bills the user and provides a portion of the revenue to the application 
provider. Conversely, the application provider may receive the revenue from the 
user, for example credit card transaction or account transfer, and have to provide a 
5 portion to the operator. In this case, the billing header could allow the operator to 
track the amount due from the application provider. 



Event messages are created in a binary Tag, Length, Value* (TLV) format. Each 
message has a numeric identifier, called the Event ID. The table below illustrates 
10 some example messages. Also shown is an example list of parameters, which might 
be included in the message. Every message is separately configurable as to whether 
or not it is logged to the Billing Manager. A number of parameters are common to 
every message. They are: 



EVENT.ID 

DATE.TIME 

EVENT_LINKAGE_ID 

15 



Event ID 


Description 


Parameters present 


3003 


Confirms that a transaction response has been 
received by the client. 


SOURCE_ADDRESS 

SOURCE_PORT 

BEARER_TYPE 

MSISDN 

CLIENT ID 

PDU_S1Z£ 


3004 


A timeout occurred when waiting for a 
confirmation of a transaction response from the 
client. 


SOURCE_ADDRESS 

SOURCE_PORT 

BEARER_TYPE 


3005 


There has been a WMLScript compilation 
failure. 


SOURCE_ADDRESS 

SOURCE_PORT 

BEARER.TYPE 


3010 


There has been a WML encoding failure. 


SOURCE^ADDRESS 
SOURCE PORT 
BEARER.TYPE 


3013 


Generated when the network is unavailable 
(e.g. the requested site does not exist or a 
timeout occurred trying to connect to the site) 


SOURCE_ADDRESS 

SOURCE.PORT 

BEARER.TYPE 

DEST_ADDRESS 

DEST_PORT 

MSISDN 
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CLIENTJD 


3014 


An HTTP response has been received from the 
origin server. 


SOURCE.ADDRESS 

SOURCE_PORT 

BEARER.TYPE 

STATUS 

URI 

CONTENT.LENGTH 

MSISDN 

CLIENTJD 

BILL HTTP.HEADER** 
BILL_HTTP_VALUE** 


3017 


An HTTP request has been received from the 
handset. 


SOURCE.PORT 
BEARER_TYPE 
URI 

MSISDN 
CLIENTJD 

CLASS_OF_INTERFACE 
USER AGENT_HEADER 
CLASS_OF^SERVICE 



As is clear from the above only the message for event 3014 has a bUling header. 
Many event messages do not include headers because: 



5 o Only the application knows whether a useful service has been provided to the 
user, and so the application decides the transactions for which to return a billing 
header. Therefore, the billing header may not have been returned for some 
ttansactions and therefore cannot be included in the events resulting from that 
transaction. 

1 0 o Some events are recognised by the gateway before the web server ha? returned the 
response to the request. For example an event might be that a request had been 
received from the client, or that the request has been forwarded to the Web 
server. Since no response has yet been received from the Web server, no billing 
header exists and therefore cannot be included in any events. 

15 o The gateway may produce a number of event messages once the response is 
returned from the Web server. If the billing header was included in the response, 
it does not need to be included in every event message because: 
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The first byte has the most significant bit set, so a second byte is read. The second 
byte doesn't have the most significant bit set so no more bytes are read. Excluding 
the most significant bits, the two sets of 7 bits make up a 14 bit number: 



l£ 1° i-P L-A il 1-0 Li 

5 

The value of this number is 141 in decimal. 

o The format of the value itself depends on the type of the tag. Below are some 
example tags. Each event will juse the appropriate set of tags required to represent 
10 its parameters. 



Tag 


Name 


Type 


Notes 

The HTTP status code. 


n « n n n 

UXUUU D 

0x0007 


STATUS 

SOURCE_ADDRESS 


Integer value 
Dotted quad or 
ASCII text 


The address is encoded depending on the 
Bearer type. If the Bearer is ANY_ANy_lPV4, 
then the address is an integer value suitable for 
an Internet address. If the Bearer is 
GSM_SMS_GSM_MSISDN, then the address 
is SMS encoded as ASCII text. 


0x0008 


SOURCE_PORT 


Integer value 


Port number which matches the Source 
address. 


0x0009 


BEARER_TYPE 


Integer value 


Values as defmed by WAP. AN Y_ANY_IPV4 
= 0. GSM SMS GSM.MSISDN = 3. 


OxOOOA 


DEST ADDRESS 


Dotted quad or 
ASCII text 


Encoded in the same way as the Source 
address. 


OxOOOB 


DEST_PORT 


Integer value 


Port number which matches the Destination 
address. 

The URI which has been accessed. 


OxOOlA 
0x0024 


URI 

EVENT_LINKAGE_1D 


ASCII text 
Integer value 


This is the identifier used to link all events 
related to a particular transaction together. It is 
a 32-bit number. 


Ox002B 
Ox002E 


EVENT__ID 
DATE TIME 


Integer value 
Integer value 


This number identifies the event itself as 
defmed in the table in Chapter 6. 
Epoch time when the event was generated. 
The length of the retrieved content. 


0x0032 
0x0048 
Ox004A 


CONTENT LENGTH 
MSISDN 

BILL_HTTP_HEADER 


Integer value 
ASCII text 
ASCII text 


Represents an MSISDN number. 

The name of the in-band billing header (always 

'*x-up-billinfi-info"). 


0x0048 


BILL_HTTP_VALUE 


ASCII text 


The corresponding value for the m-band billing 
header. 


0x0056 


PDU_SIZE 


Integer value 


Size in bytes of the WSP PDU transmitted over 
the bearer- 
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All events can be associated via the ELID and therefore the billing header 
only needs to be included in at least one event 

- On a system with high traffic levels, the processing and storage of 
unnecessary or redundant data needs to be avoided. For example, it could 
5 cause increased use of disk storage space, performance degradation, or 

unnecessary use of bandwidth on the real-time connection, all of w^hich 
represent some form of cost for the operator. 

All parameters are represented in a binary TLV format. Each parameter is composed 
10 of three parts: A numeric tag' which identifies the parameter name; a length which 
represents the length of the value in bytes; and the value itself These three parts are 
defined as; 

o The numeric tag is always represented with two bytes. See below for a table 
1 5 below defining some example tags. 

o The length is represented with one or more bytes, with the most significant bit in 
each byte being used to indicate if the next byte is also part of the length. This is 
known as Extension-Bit format. After reading the first byte, if the most significant 
bit is set then the next byte is also read. This continues until a byte read does not 
20 have the most significant bit set, up to a maximum of 5 bytes. The numbers 
represented by the least 7 significant bits of each byte are then used to give the 
total length. An example is: 

The number 0x8 lOD would be decoded as: 

25 



BYTE 1 














i BYTE 


2 












i 


1 1 0 


i 0 


i 0 


I 0 


i 0 


1 0 


1 1 


i 0 [ 


0 


1 0 


0 


i 1 


i 1 


1 0 


'FT'""" 1 
■ J 
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It will be appreciated that the invention allows for control of billing data in a simple, 
reliable, and versatile manner. For example, this allows choice of which party 
obtains the "value-added" benefit for transactions or other application operations. It 
also allows pre-paid billing functionality by providing data for a subscriber account 
5 on a pre-paid billing platform. This may, for example, be used to determine if 
requested content should be returned to the subscriber. The returned data could also 
be used to influence other decision-making procedures in the gateway. Because the 
log entry is made after the client acknowledgement, the user will not be billed if there 
is a transmission error or if the user cancels. 

10 

The invention is not limited to the embodiments described but may be varied in 
construction and detail. For example, while the event messages are received and 
processed by a WAP gateway, they may alternatively be processed by any routing 
node between the application and the user device. The term "gateway" is intended to 
1 5 mean any such node or device. 
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Claims 

1. A method of capturing billing data for operation of an application on a 
network server communicating with a chent via a gateway, the method 
comprising the steps of:- 

the application automatically generating billing data relating to a service it 
provides; 

the application automatically transmitting the billing data to the gatev^^ay; and 
the gateway processing the billing data. 



2. A method as claimed in claim 1, v/herein the application transmits the billing 
1 5 data in an event message according to a pre-set format. 

3. A method as claimed in claim 2, wherein the message comprises a HTTP 
header. 

20 4. A method as claimed in any preceding claim, wherein the application 
generates a message for each activity recognised as an event and transmits 
said messages to the gateway. 

5. A method as claimed in claim 4, wherein the application recognises a 
25 plurality of events for a transaction. 

6. A method as claimed in claim 5, wherein the application includes a common 
event linkage identifier in each event message associated with a particular 
transaction. 

30 
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7. A method as claimed in any of claims 2 to 6, wherein the application 
recognises a transaction failure as an event. 

8. A method as claimed in any of claims 2 to 7, wherein the application 
recognises a time-out as an event. 

9. A method as claimed in any of claims 2 to 8, wherein each event message has 
a unique identifier. 

j 

10. A method as claimed in claim 9, wherein the identifier is a number whereby 
identifiers of sequential messages are sequential numbers. 

11. A method as claimed in any of claims 2 to 10, wherein each event message 
comprises at least one parameter value. 

12. A method as claimed in claim 11, wherein each parameter value is 
represented in a tag-length-value format in which a tag field identifies a 
parameter name, the length field identifies the length of the value in bytes, 
and the value field contains the parameter value. 

13. A method as claimed in any preceding claim, wherein the gateway generates 
billing data according to signal flows between the application and the client, 
and stores said billing data in addition to that originating ft-om the 
application. 

14. A method as claimed in any of claims 2 to 13, wherein the gateway recognises 
events according to signal flows between the application and the client, and 
generates corresponding messages. 
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15. A method as claimed in any of claims 2 to 14, wherein the gateway routes 
event messages to a billing log for off-line processing or to a real time 
mediation device for real time processing according to configuration settings. 

5 16. A method as claimed in claim 15, wherein the gateway routes event messages 
to the real time mediation device if the events relate to pre-paid services. 

I 

17. A method as claimed in any preceding claim, wherein, within the gateway, 
messages are routed in real time to a billing manager, and said billing 

1 0 manager processes the messages. 

18. A gateway for routing of signals between a client and an application hosted 
on a network server for performance of a transaction, the gateway 
comprising: 



15 



20 



means for receiving billing data from the application, said billing data relating 
to a service provided by the application; and 

means for processing the billing data. 

19. A gateway as claimed in claim 18, wherein the processing means comprises 
means for classifying the data as requiring real time processing or off-line 
processing, and for routing the data accordingly. 



25 20. A gateway as claimed in claims 18 or 19, wherein the billing data is 
incorporated in event messages. 

21. A gateway as claimed in claim 20, wherein the gateway comprises means for 
generating event messages according to handling of signals for transaction. 

30 
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22. A gateway as claimed in any of claims 18 to 21, wherein the gateway 
comprises a billing manager, means for routing billing data in real time to the 
billing manager, and means in the billing manager for direaing storage of the 
data in a log for off-line processing or for routing the data to a real time 

5 mediation device for real time processing. 

23. A billing system comprising: 

a gateway as claimed in claim 22; 

10 

a mediation device comprising means for reading billing data in a billing log 
which is updated by the gateway and for processing said billing data; and 

a real time mediation device comprising means for performing real time 
1 5 processing of billing data received from the gateway. 

24. A computer program product comprising software code for performing the 
steps of any of claims 1 to 1 7 when executed on a digital computer. 
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